home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / sdkdigv8.zip / SDKV8N18.TXT < prev    next >
Text File  |  1994-01-20  |  7KB  |  176 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Programmer's Digest     Thu, 20 Jan 94  4:06         Volume 8: Issue  18  
  5.  
  6. Today's Topics:
  7.                               Envelopes
  8.                 Scaling Frequency for correct note ...
  9.                     Sources on Programmers Digest
  10.  
  11. Standard Info:
  12.     - Meta-info about the GUS can be found at the end of the Digest.
  13.     - Before you ask a question, please READ THE FAQ.
  14.  
  15. ----------------------------------------------------------------------
  16.  
  17. Date: Wed, 19 Jan 1994 20:32:32 -0500 (EST)
  18. From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
  19. Subject: Envelopes
  20.  
  21. > Date: Tue, 18 Jan 1994 12:13:40 -0600 (CST)
  22. > From: Jason William Whiteman <jww9624@tamsun.tamu.edu>
  23. > Subject: Envelope offsets
  24. > 
  25. > > > I am taking the envelope offset values to be an addative value (always
  26. > > > with respect to the initial volume) unless the envelope offset is 
  27. > > > below a threshold point.  Because you cannot add any positive value
  28. > > 
  29. > > I'm not quite clear on what you're getting at.  The offset is absolute,
  30. > > not additive, as far as I'm aware.
  31. > 
  32. >     If envelope values are absolute volumes for the patch, then you
  33. > could never set the volume of the patch playing softer or louder.  If they
  34. > were absolute volumes, then the volume would always be set at whatever
  35. > the envelope values say.. However, we can both agree that the OVERALL
  36.  
  37. The envelope offsets are absolute when taken in isolation.  I was 
  38. under the impression that we were discussing the envelope for one voice
  39. unattenuated by factors such as channel volume and expression, and thus
  40. couldn't make heads or tails of why you'd treat the offsets as additive.
  41.  
  42. > volume (disregarding the envelope) can be increased or decreased.  
  43. > Superimposed over this OVERALL volume are the volumes of the individual
  44. > envelope offsets.
  45.  
  46. Since the GUS' volume is log instead of linear, with a zero volume setting
  47. of zero and not negative infinity, I'm not sure how we'd go about attenuating
  48. the envelope offsets.  Do we substract some x from the offsets based on the
  49. channel volume?  I think this would be the way it's done for a true log scale
  50. (i.e. one that goes to negative infinity for zero volume).  For the GUS,
  51. it's probably best to treat everything linearly, and just use the following
  52. formula:
  53.  
  54.   linoffset = chan_vol/127 * expression/127 * absoffset
  55.   logoffset = log(linoffset + 1)/log(128) * K
  56.  
  57. Logoffset would be the value we'd poke into the GUS' voice volumes and 
  58. ramp points.
  59.  
  60. Disclaimer:  The above was typed in with hurried thought.  Correcting
  61. my mistakes is left as an exercise for the reader. :)
  62.  
  63. Phat.
  64.  
  65. ------------------------------
  66.  
  67. Date: Wed, 19 Jan 94 09:53:50 EST
  68. From: support@fortech.com (Technical Support)
  69. Subject: Scaling Frequency for correct note ...
  70.  
  71. Hello,
  72.  
  73. > frequency for the GUS to play the patch at.  What I would now like to know is 
  74. > how to scale the frequnecy to play say a G4 when the original sound was 
  75. > recorded at C4.  Surely, the root freq and may be the sampling freq have to 
  76. > taken into consideration.  Do I work it out by multiplying ( or dividing, 
  77. > which ever the case may be) the root freq by the twelfth root of two ( 
  78. > 1.0594..) and working out the freq that way?
  79.  
  80.  
  81. First, lets explain a couple of terms for those who don't know what they
  82. are.
  83.  
  84. Root Frequency - Frequency of the thing recorded.
  85. Sample Frequency - Sample Rate at which the root frequency (or tone) was
  86.                    recorded.
  87.  
  88. Example:
  89. a 1Khz tone recorded at 44.1khz would have a root freq of 1Khz and
  90. a sample frequency of 44.1khz
  91.  
  92.  
  93. First, calculate the sample ratio. There is a sample ratio for EACH
  94. wave sample in a patch (up to 16). This must be scaled by the frequency
  95. divisor for the # of active voices (This table is in SDK,vocfreq.c). 
  96. Adding in 1/2 the sample rate (sample>>1) is to allow for rounding. 
  97. This calulation can be done at patch load time and saved on a per-wave 
  98. basis since this will not change (unless # active voices change .... )
  99.  
  100. sample_ratio = ((ULONG)
  101.         (freq_divisor[active_voices-14]) * 512L +
  102.         (ULONG )(sample_rate>>1)) /
  103.         (ULONG )sample_rate;
  104.  
  105. Now when you are ready to do a note on, calulate the FC based on the
  106. pre-calculated sample ratio, root freq and desired playback frequency.
  107.  
  108. USHORT Calculate_FC(unsigned int sample_ratio, long root, long frequency)
  109. {
  110.     ULONG freq_register;
  111.  
  112.     freq_register  = (((ULONG)frequency * 512L) +
  113.              (ULONG)(root>>1)) /
  114.              (ULONG)root;
  115.     freq_register  = ((ULONG)freq_register * 512L +
  116.                (ULONG)(sample_ratio>>1)) / 
  117.                sample_ratio ;
  118.     return((USHORT)freq_register);
  119. }
  120.  
  121. Make sure you use large enough variables (ULONG) since some of the
  122. the intermediate values get VERY large.
  123.  
  124. Hope this helps.
  125.  
  126. Forte Tech Support
  127.  
  128. ------------------------------
  129.  
  130. Date: Thu, 20 Jan 94 09:52:51 GMT
  131. From: Flynn Peter R BSc 1 Mod Comp 93-94 <P.Flynn@teesside.ac.uk>
  132. Subject: Sources on Programmers Digest
  133.  
  134. I thought the programmers digest would be a clinic for ailing programmers. 
  135.  
  136. It would be nice if example sources were placed often.  
  137.  
  138. The Gravis Developers Kit is OK but examples in C aren't really that good
  139. to me as I am reaching all the hardware from PM386 Assembler.
  140.  
  141. I really need a better source site than ftp.uwp.edu
  142.  
  143. Speech recognition on the GUS is a problem.  Not that the GUS can't do
  144. it but because of the amount of space used to store recognition data.
  145.  
  146. A multi-user recognition package would go down a treat but until then we are
  147. limited by the systems we are using.
  148.  
  149. Hmm :-(
  150.  
  151. Peter Flynn
  152. SHADE    
  153.  
  154. ------------------------------
  155.  
  156. End of GUS Programmer's Digest V8 #18
  157. *************************************
  158.  
  159. To post to tomorrow's digest:                    <gus-sdk@dsd.es.com>
  160. To (un)subscribe or get help:            <gus-sdk-request@dsd.es.com>
  161. To contact a human (last resort):          <gus-sdk-owner@dsd.es.com>
  162.  
  163. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  164.                      wuarchive.wustl.edu            /systems/ibmpc/ultrasound
  165.                      archive.orst.edu                    /pub/packages/gravis
  166.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  167.                      nctuccca.edu.tw                           /PC/ultrasound
  168. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  169.  
  170. Hints:
  171.       - Get the FAQ from the FTP sites or the request server.
  172.       - Mail to <gus-sdk-request@dsd.es.com> for info about other GUS
  173.     related mailing lists (general use, musician's, etc.).
  174.  
  175.  
  176.